NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/6703

Internet Message Format | 1996-08-05 | 5.4 KB

Path: beavis.kronos.com!usenet
From: [e-mail] (Porter Woodward)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: AB3D II beats Quake....
Date: 1 Apr 1996 12:44:20 GMT
Organization: Software Quality Assurance
Distribution: world
Message-ID: <4joj34$[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: 158.228.60.147
Mime-Version: 1.0
Content-Type: Text/Plain; charset=US-ASCII
X-Newsreader: WinVN 0.99.7

In article <[e-mail]>, [e-mail] says...
>
>In a message of 28 Mar 96 Stephan Schaem wrote to All:
>
>Sure, but I bet it costs Intel more than 10 times as much money to get the P6
>to perform as well as the PPC604.  Just think of what the PPC604 could have
>been with 10 times as large a budget.  Also I think integrating a huge cache on
>the chip had a LOT more to do with the current performance of the P6 (and of
>course the usual overinflated Intel specmarks).
>
    It made a huge difference!  In a register poor environment like a x86
chip - you have to have a large on chip cache to make up for the deficiencies
of the slow operation of memory fetches!  This in turn can push the price of a
chip up - In fact, to achieve "decent" preformance, P5s need L2 cache - and,
believe me that ain't exactly cheap.

> >> Again, I don't agree. The problem is not the size of the opcode, but the
> >> time needed to execute it. Allowing 1 byte opcode means you won't be able
> >> to do pipelining and predecoding of the instructions flow. I don't think
> >> any chip firm today would go that way, ie using 1 byte opcode.
>
> SS>  Its hard to say what would be the best instruction size/format...
>
>Maybe, but I think there are definitely very good reasons not to use 16 bit or
>8 bit instructions sizes anymore.

    That's the truth.  Why limit ourselves to itsy bitsy instruction sizes
anymore.  Although there are a finite number of instructions that are feasible,
it would be useful to have a 64bit instruction size so that later expansion of the
instruction set wouldn't tromp all over the existing instructions.

>
> >> >Intel is not dumb, they said 3 years ago what I understood nowadays.
> >> >Time for other people to understand it as well. >
> >> Intel is producing mass CPU, not clever CPU. I'm much more interested in
> >> work and advices from HP, MIPS, ...
>
> SS> Intel also design advance risc that even SGI used for high end
> SS> geometry engine. HP also use intel risc in mass quatity. Intel
> SS> is not stupid and has ALOT of resource to take crap design like
> SS> the x86 and turn it around to be a performer.
>
>Performer?  Why not divide the 'performance' by the price-tag and compare it
>with other chips.
>
    Intel is plenty clever.  Although I wouldn't rate the x86 design as
an "elegant" one, it is effective.  And that is what matters.  Additionally,
couple that with the fact that most professional business software runs on
an OS that pretty much only runs on Intel processors...  And there is very
little for them to worry about.

    A PPC604 with native software, etc. Is quite impressive in terms
of speed - Easily as fast as a Pentium, and with hand tuned code, much
faster.  There are just some things that are possible with RISC that are
much harder to do in CISC.  And forget that crap about a 620 being slow.
You are talking Sparc/MIPS performance.

> >> One of the big problem with the x86, is the poor number of register and
> >> the way they have to be used. Really, having 32 or 64 regs (PPC) greatly
> >> helps speeding up execution (as an  ASM supporter, I think you will agree
> >> on the importance of the number of registers).
>
>C compilers like lots of registers as well, especially if they are general
>purpose registers.  It not only makes good compilers easier to write (there are
>a lot less rules to be taken into account), it probably also makes for faster
>compile times (less special cases to check and optimize).
>
    It's only recently that compilers have started taking major
advantage of register rich environments.  That is one of the major
reasons that RISC was unable to prove it's superiority over CISC years
ago.  We're talking early 80s here.  C was just coming into 'Vogue', and
compiler technology wasn't in any way shape or form as advanced as
it is now.

    Now, compilers can in-line function calls, unroll loops, etc.  A number
of the tricks that we do with hand tuned code are still beyond them, but
the things that they can do are the tasks we would find quite tedious.
--
****************************************************************
             (Oh, so that's what's on the other side!)
            o   "Sometimes truth IS stranger than fiction."
           o  I can be reached at:
          o   [e-mail] -daytime
       \|/    OR     [e-mail]        -nights
       @ @    OR   http://www.kronos.com/~porter/ -always
___oOO_(_)_OOo__________________________________________________
   |   |   |   |   |   |   |   |   |   |   |   |   |INTEL  |   |
   |+------------------------------------+ | @ |   |  OUTSIDE  |
   ||  //\                               | |   |   |   |   |   |
   ||\X/--\MiGA - Make up your own mind. | |   |   |JUST SAY NO|
@  |+------------------------------------+ |   |  o|   | TO|   |
   |   |   |   |   |   |   |   |   |   |   |*  |   | Micro$oft |
////////////////////////////////////////////////////////////////